---
type: engineering-note
title: Two-Axis Review
description: Review every diff on two axes — Standards (is the code good) and Spec (does it match the documented rows) — and block on the second.
tags: [engineering, skill]
timestamp: {{DATE}}
---
<!-- ✂ docujoint template sample — replace with your own content, then delete this comment. -->
# Two-Axis Review

_Adapted for this knowledge base from
[Matt Pocock's engineering skills](https://github.com/mattpocock/skills/tree/main/skills/engineering)
(code-review)._

## When to use
Every pull request, human- or agent-authored.

## Axis 1 — Standards
The usual craft: naming, structure, error handling, tests that assert
outcomes. Advisory unless egregious.

## Axis 2 — Spec (blocking)
The diff is checked against the knowledge base, not against the reviewer's
memory:

1. **Find the rows.** Which `## Features` / `## Scenarios` rows does this
   diff implement or change? If none exist, the spec is missing —
   see [Docs-First Implementation](</Engineering/Skills/Docs-First Implementation.md>).
2. **Rows updated in the same PR?** `Implemented` cells cite the new code
   (`repo:// api:// db://`), tests are cited, gaps that closed are cleared.
3. **Contracts honoured?** New columns match the table doc; new states exist
   in the enum doc; new messages match the event's `## Message`.
4. **Doubts surfaced?** Anything the author guessed at should be an open
   question, not a silent assumption.
5. **`dj lint --warnings-as-errors` is the merge gate** — a diff that
   makes the vault dirty does not merge.

## The rule of thumb
Axis 1 failures cost a review cycle. Axis 2 failures cost the next person a
wrong mental model — that is why only axis 2 blocks.

## Open questions